Field of the Invention
The present disclosure relates to routing. In particular, but not exclusively, the present disclosure relates to routing packet data.
Description of the Related Technology
Known networks comprise a customer having an internet protocol (IP) network with multiple high-scaled data hosts, such as a content distribution network (CDN). The hosts send large amounts of data toward the Internet, and so the customer requires a router device to route packets between the hosts and various access connections to consumers over the internet. There may also be a relatively small amount of traffic flowing to/from a data center, which is located behind a further router device.
The router device in such a network has high scale requirements. It needs to handle a large IP routing table (for example of the order of 500,000 routes, the size of the Internet's default free zone), and also handle the large amount of bandwidth required. Routers with both of these characteristics are expensive.
Cheaper alternatives tend to handle one of the above scale requirements but not both. OpenFlow-controlled devices with dedicated routing hardware can handle the bandwidth but are not usually capable of handling as many as 500,000 routes in the data plane. Linux-based “virtual” routers with software data planes running on x86 hardware can handle 500,000 routes but cannot handle the large bandwidth required.
Another approach to scaling the system is to divide the responsibility. A commercial off-the-shelf (COTS) Linux virtual router handles the routing decision. The bandwidth is kept low by running many such systems, so each one only handles a small subset of the data. One easy way of doing this is to use the hosts themselves as routing engines. A cheaper OpenFlow device with dedicated hardware handles the packet forwarding. The routing decision has already been made by the COTS Linux systems, so this work is removed from the OpenFlow device. A method of tagging the routing decision on a packet-by-packet basis is required.
There are multiple ways of tagging each packet with the result of the routing decision. The OpenFlow enabled forwarding device needs to be able to match tag, and remove it before forwarding on to the selected next hop. Two known ways of tagging are multiprotocol label switching (MPLS) labels and 802.11Q virtual local area network (VLAN) tags. Linux does not support MPLS-labeled packets, which is a drawback to the approach of using MPLS. Linux does support VLAN tagged interfaces, but there is no standards-based method to signal the mapping between the routes and VLAN identifiers.